Progress Report

ion-neutral The core will be ‘mid-level’: it will be platform independent, garbage-collected, etc., but will not provide direct support for higher-level abstractions. Lower-level notions can be implemented as transforms directly into the target language, and higher-level abstractions can be implemented as transforms into simpler objects. Portable As noted above, low-level features will be independent of the core. In addition, the code generation interfaces will be made as narrow as possible to minimise the work required to implement a new target. The build environment is likely to consist of a single command which takes a directory full of source files and compiles them (incrementally if possible) into a package. Also specified will be a set of standard search paths for packages on each platform, and standard mechanisms for querying package versioning, capability, and dependency information. A complete standard library specification will not be given; it is assumed that one would exist were the language to come into production use. Compatible The easiest way to ensure compatibility would be to specify C calling conventions, however this would preclude e.g. compiling to bytecode targets. Further, the C and even C++ calling conventions are in some places inadequate for an efficient implementation. Calls across language boundaries are in general done using wrappers which translate calling conventions and types as necessary. These are usually created by hand, or automatically using programs such as SWIG. META2 programs should have no need for this since the transformation system allows wrapper code to be generated seamlessly as part of the build should it be desired. Parsable The nature of the transformation system means that batch-mode parsing of META2 code can easily be done using META2, but this will not be appropriate for real-time parsing as is necessary for syntax highlighting. However, the main syntax invariant imposed by the language is that square brackets (used to delimit constructions) must always nest correctly. Therefore, even though a simplistic parser may not always be able to discern or parse the grammar used within a given construction, it is guaranteed to be able to recover and continue parsing the rest of the code. 3 Compiler design and implementation decisions The chief aim of this project is the design of the META2 language and core library interfaces. The implementation is a secondary task intended primarily to demonstrate that the language is implementable. As such, my intention for the implementation is to minimise the work necessary to produce a working compiler, so as to leave as much time as possible to devote to the language design. Based on this principle, I have made the following decisions in the design of my implementation: 3.1 Evolutionary design Since this is a prototype compiler for an experimental language, it will not be appropriate to follow the classical specify-design-code software development methodology. The design of META2 blurs the usual distinction between the language, its compiler, and its libraries, and my usage of the object model during implementation will represent important feedback as it its suitability. Were I to attempt to design the system completely before beginning its implementation, I would have no way to assess its quality. Thus, my primary up-front design effort is for a modular framework which will allow me to add functionality incrementally, developing the language specification as I go.